Ok, tests added, and changelog.md tagged as 9.4.0

Hi, interesting! The only doubt I have concerns whether there is a problem regarding data security, in the sense that by doing so you offer an api that any vendor could use and intercept / listen to past data (maybe manipulate them?) without you realizing it. Is what I say correct or I miss something (maybe paranoia 😅)? Anyway thanks for the PR.

Yes, that’s right, that’s why I need it 😅
If the goal is to protect the library from external vendors, this vendor would still have the possibility of injecting itself by extending the configuration of execution middleware before the app container resolves GraphQL, which generates the same risks.

It could also be placed at the top level (Http Kernel Middleware), in which case the library itself would not be able to ensure "its own security"

Yes, I don't think we can act to protect in some way, it was just a thought on the matter that I wanted to share.

@mfn Can you merge please?

I've a feeling there's something missing from the PR.

A LOT of behaviour is controlled via the config file, you can define all the schemas, middlewares (resolver middlewares) and execution middlewares there.

In fact, you can already define execution middlewares per schema and global one. However, the per-schema execution middlewares completely override the global one.

Therefore I think, adding the ability to append global resolver middlewares but not exposing them in the config (resolver_middleware_append?) seems imbalanced.

WDYT?

It's a good idea, I push new changes with possibility to use resolver_middleware_append key in config file too.

As the middleware receives the schema information as the first parameter, I do not think that it is useful to complicate the code base with management by schema, it will be enough for the middleware to do nothing if the schemaName is not suitable.
This will also allow the middleware to apply their own logic based on the schema

Released!